LGTM.

My only concern here is dropping connection timeout. It would definitely be a corner case that the socket exists but kubelet is not responding. I'm not too familiar with grpc, so I don't know if this could lead into a situation where our plugins that use podresapi would stop responding, too, and get kicked out from container runtime.

@klihub, do you think this can cause issues, or do you think plugins will recover just fine when kubelet is alive again?

Dropping (connection establishment) timeout and the other changes were made based on the gRPC documentation, in particular the API functions we stopped using being marked as deprecated. That's why, for instance, we gave up using WithBlock().

I haven't checked the code but I think what happens is that an asynchronous connection establishment in the background is triggered by grpc.NewClient() and it returns immediately, without blocking. This was already the default behavior without the extra WithBlock() option. Then if a request is coming while connection establishment is still going on, the timeout for that request eventually kicks in if connection establishment is too slow.

There are potential annoying side-effects if the socket/RPC endpoint is optional, either there or not based on some config, but AFAICT that is not the case with the Pod Resource API socket. One real danger here is could be that if the initial connection establishment took way too long, then our very first API query could time out because of that but subsequent ones succeed... but if that starts showing up, we could do an extra List() or Get() as part of podresapi.NewClient() to make sure the connection is up.